Recording apparatus and method, program, and storage medium

ABSTRACT

Disclosed herein is a recording apparatus for recording a file stream which may be composed of a header, a body, and a footer onto a storage medium. The apparatus may includes header area securing means for, before recording of the body, securing in a recording area of the storage medium a header area in which the header is to be recorded; recording means for recording the body and the footer in the recording area of the storage medium, re-securing the header area secured by the header area securing means based on areas in which the body and the footer have been recorded, and recording the header in the re-secured header area; and reflecting means for allowing information concerning the header area secured when a recording process performed by the recording means is terminated normally or abnormally to be reflected in a file system of the storage medium.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from Japanese Patent Application No. JP2006-149929, filed in the Japanese Patent Office on May 30, 2006, theentire content of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a recording apparatus and method, aprogram therefor, and a storage medium having the program storedtherein. In particular, the present invention relates to a recordingapparatus and method, a program therefor, and a storage medium havingthe program stored therein, which allow easy and proper storage of afile system even when a recording process is terminated abnormally.

2. Description of the Related Art

As a method for preventing occurrence of a seek when recording a filestream composed of a header portion, a body portion, and a footerportion onto a storage medium such as an optical disk, there is a knownmethod of arranging (i.e., recording) the above portions in a recordingarea of the storage medium in the following order (i.e., inchronological order in which data of these portions appear): the bodyportion, the footer portion, and the header portion (see, for example,Japanese Patent Laid-open No. 2005-4853).

According to this recording method, a footer area in which the footerportion is recorded and a header area in which the header portion isrecorded are located within the recording area of the storage medium soas to follow a body area in which the body portion is recorded.Therefore, a final location of the header area is not determined untilthe recording of the body portion is completed.

Specifically, during recording of a file, information concerning therecording area of the file is held in a memory within a recordingapparatus, and at the time when the entire recording operation iscompleted, that information is reflected in a file system managementarea of the storage medium (on which the writing has been performed).For example, address information of the header area, the body area, andthe footer area are held in the memory, and after the recording of theheader, body, and footer portions is completed, the address informationheld in the memory is written to a file used for managing the filesystem recorded on the storage medium (i.e., information in the filesystem management area is updated).

Therefore, in the case where a power of the recording apparatus iserroneously turned off or a system hang-up erroneously occurs while thebody portion is being written to the storage medium and thus therecording process is terminated abnormally, for example, theabove-described recording method is not able to allow the file of whichthe recording has not been completed to be reflected in the file systemin the storage medium in a format that is valid for the file system.That is, the file of which the recording has been terminated abnormallyin the course of recording is regarded as “a file not recorded” in thefile system.

When this occurs, salvaging means independent of a standard of the filesystem is required to recover the file (see, for example, JapanesePatent Laid-open No. 2006-65912). According to this method,predetermined information called a “salvage marker” is recorded at apredetermined interval when recording data on the storage medium, andwhen data recovery is performed after abnormal termination of therecording process, data that has not been reflected in the file systemis searched for based on the markers as recorded, and informationthereof is reflected in the file system.

Such a recovery method is effective particularly when the power of therecording apparatus has been erroneously turned off or the systemhang-up has erroneously occurred to prevent the recording process fromcontinuing (i.e., in the case where information concerning the recordingcannot be reflected in the file system at the time of the abnormaltermination).

SUMMARY OF THE INVENTION

In the case where similar recording is to be realized by applicationsoftware, a file system driver (FSD), and the like that run on anoperating system (OS) in a general-purpose personal computer or thelike, the abnormal termination of recording is, in many cases, caused byabnormal termination of the application software. When the abnormaltermination of the application software has occurred, it is difficultfor the FSD to detect the abnormal termination of the applicationsoftware; but, as the OS is still operating (i.e., the OS has not beenterminated), the FSD is, in the case of an ordinary recording method,able to allow the information concerning the halfway recording to bereflected in the file system (i.e., file system management information)of the recording area of the storage medium to convert the data that hasbeen recorded up to the abnormal termination into a format that complieswith the standard of the file system of the recording area of thestorage medium.

In other words, even if the abnormal termination occurs, it is possibleto record the data so that the application software as re-activated (orsimilar application software that is executed on another personalcomputer) can resume the recording of the file easily without the needfor the above-described data recovery.

As the header portion precedes the body portion in the file stream,declaration of an area for the header portion in the file system isrequired to achieve the above operation. In the above-describedrecording method as disclosed in Japanese Patent Laid-open No.2005-4853, however, the final location of the header area is notdetermined until the recording of the body portion is completed, asdescribed above; therefore, the declaration of the area for the headerportion is not possible until the writing of the body portion iscompleted.

Accordingly, in the case where the abnormal termination of theapplication software has occurred because of a bug of the applicationsoftware, resource shortage of the personal computer, or the like, thereis a probability that the data that has been recorded up to the abnormaltermination cannot be converted into the format that complies with thestandard of the file system of the recording area of the storage medium.That is, when the recording of the file is terminated on the way becauseof the abnormal termination of the application software, there may be noother option than to perform the above-described data recovery by thespecial method as disclosed in Japanese Patent Laid-open No. 2006-65912,which is independent of the file system. This method may require anincreased processing load and time to obtain proper data. In addition,because of the specialty of the above-described data recovery, there isa probability that the above-described data recovery cannot be performeddepending on an environmental factor of the personal computer or thelike.

An advantage of the present invention may be to achieve easy and properstorage of the file system even when the abnormal termination of therecording process has occurred.

According to one embodiment of the present invention, there is provideda recording apparatus for recording a file stream which may be composedof a header, a body, and a footer onto a storage medium, the apparatuswhich may include header area securing means for, before recording ofthe body, securing in a recording area of the storage medium a headerarea in which the header is to be recorded; recording means forrecording the body and the footer in the recording area of the storagemedium, re-securing the header area secured by the header area securingmeans based on areas in which the body and the footer have beenrecorded, and recording the header in the re-secured header area; andreflecting means for allowing information concerning the header areasecured when a recording process performed by the recording means isterminated normally or abnormally to be reflected in a file system ofthe storage medium.

According to another embodiment of the present invention, there isprovided a method for recording a file stream which may be composed of aheader, a body, and a footer onto a storage medium, the method mayinclude before recording of the body, securing in a recording area ofthe storage medium a header area in which the header is to be recorded;recording the body and the footer in the recording area of the storagemedium, re-securing the header area secured by the securing step basedon areas in which the body and the footer have been recorded, andrecording the header in the re-secured header area; and allowinginformation concerning the header area secured when a recording processperformed by the recording step is terminated normally or abnormally tobe reflected in a file system of the storage medium.

According to one embodiment of the present invention, a header area tobe provided within a recording area of a storage medium and in which aheader is to be recorded may be virtually set before recording of abody, whereby the header area may be secured provisionally; a body and afooter may be recorded within the recording area of the storage medium;the secured header area may be re-secured by being re-set based on areasin which the body and the footer have been recorded; the header may berecorded in the re-secured header area; and information concerning theheader area secured when a recording process is terminated normally orabnormally may be caused to be reflected in a file system of the storagemedium.

According to embodiments of the present invention, recording of a filemay be achieved. In particular, even if a recording process isterminated abnormally while the file is being recorded onto a storagemedium such that pieces of data in the file are recorded in apredetermined order, proper storage of the file may be achieved easilyso as to comply with a file system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary structure of anoptical disk recording apparatus according to one embodiment of thepresent invention;

FIG. 2 is a schematic diagram illustrating an exemplary structure ofsoftware;

FIG. 3 is a diagram illustrating an exemplary file format;

FIG. 4 is a schematic diagram illustrating an operation model of awriting process;

FIG. 5 is a flowchart for explaining an exemplary flow of a capturingprocess;

FIG. 6 is a flowchart for explaining an exemplary flow of a recordingprocess;

FIG. 7 is a flowchart for explaining an exemplary flow of a terminationprocess;

FIGS. 8A to 8D are schematic diagrams illustrating examples ofprovisional header areas;

FIG. 9 is a diagram illustrating a recording model in the case where therecording process is terminated normally;

FIG. 10 is a diagram illustrating a recording model in the case wherethe recording process is terminated abnormally; and

FIG. 11 is a diagram illustrating another exemplary recording model.

DETAILED DESCRIPTION

Hereinafter, embodiments of the present invention will be described withreference to the accompanying drawings.

FIG. 1 is a block diagram illustrating an exemplary configuration of asystem using an optical disk recording apparatus according to oneembodiment of the present invention.

In FIG. 1, an optical disk recording apparatus 11 is an apparatus forrecording data (e.g., image or audio data) on an optical disk (i.e., astorage medium), such as a compact disc (CD) or a digital versatile disc(DVD). The optical disk recording apparatus 11 records a file containingaudiovisual (AV) data, such as image data or audio data, supplied from avideo camera 13 connected thereto via a network cable 12 onto theoptical disk in a predetermined file format.

The network cable 12 is a communication cable that complies with apredetermined standard, such as a USB (Universal Serial Bus) or IEEE(Institute of Electrical and Electronic Engineers) 1394 standard. Thenetwork cable 12 connects the video camera 13 to the optical diskrecording apparatus 11 so as to allow communication therebetween (i.e.,data exchange therebetween). In other words, the network cable 12 is acommunication medium that achieves wired communication between theoptical disk recording apparatus 11 and the video camera 13. Note that,instead of using the network cable 12, the optical disk recordingapparatus 11 and the video camera 13 may be connected to each other viaa wireless link, such as an infrared link, IEEE 802.11x, or the like, soas to allow communication therebetween.

The video camera 13 includes a camera section and a microphone section.The video camera 13 supplies the AV data, which is composed of the imagedata (e.g., a moving image or a still image) obtained by photographingvia the camera section and the audio data obtained via the microphonesection, and related data composed of information related to the AV datato the optical disk recording apparatus 11 via the network cable 12 inthe form of a file according to a predetermined file system. Note thatthe video camera 13 may be a camcorder (registered trademark) thatadditionally has a function of recording an AV file on a storage medium.In this case, the video camera 13 is able to supply the file recorded onthe storage medium to the optical disk recording apparatus 11 via thenetwork cable 12. Also note that although the video camera 13 is used inFIG. 1, the video camera 13 may be replaced by any apparatus that iscapable of supplying a file containing the AV data to the optical diskrecording apparatus 11.

The optical disk recording apparatus 11 is, for example, formed by ageneral-purpose personal computer. In FIG. 1, the optical disk recordingapparatus 11 includes a central processing unit (CPU) 21, an I/O(input/output) bridge 22, a main memory 23, a read-only memory (ROM) 24,and a bus interface (I/F) 25.

The CPU 21 is connected via the I/O bridge 22 to the main memory 23formed by a semiconductor memory such as a dynamic random access memory(DRAM), the ROM 24, which is a nonvolatile memory, and the bus interface25, which performs an interfacing process in relation to an internal bus30. The CPU 21 executes various processes in accordance with a programstored in the ROM 24 or a program loaded from a storage section 35described below to the main memory 23. The main memory 23 also stores,as necessary, data that is necessary when the CPU 21 executes thevarious processes.

The bus interface 25 is also connected to the internal bus 30. Theinternal bus 30 is, for example, a bus that complies with apredetermined standard, such as an Industry Standard Architecture (ISA)bus or a Peripheral Components Interconnect (PCI) bus. The internal bus30 connects various parts described below and the bus interface 25 toone another, and serves as a communication medium for communicationbetween those parts.

A network interface (I/F) 31, an optical disk drive 32, an input section33, an output section 34, the storage section 35, and a drive 36 arealso connected to the internal bus 30.

The network interface 31 performs a communication process by way of anetwork such as the Internet to exchange information with an apparatusexternal to the optical disk recording apparatus 11. The optical diskdrive 32 writes or read data to or from an optical disk medium 51mounted at a predetermined location thereof. For example, the opticaldisk drive 32 writes data supplied via the internal bus 30 to theoptical disk medium 51, such as a compact disc-recordable (CD-R) or adigital versatile disc-recordable (DVD-R), mounted at the predeterminedlocation. Further, for example, the optical disk drive 32 reads datarecorded on the optical disk medium 51 and supplies the data readtherefrom to the main memory 23 via the internal bus 30.

The optical disk drive 32 contains a bus interface (I/F) 41, a cachememory 42, and a media input/output control section 43. The businterface 41 performs an interfacing process in relation to the internalbus 30. The cache memory 42 temporarily holds data supplied from the businterface 41 or the media input/output control section 43 to reduceoverflow due to a difference in speed between data input and dataoutput. The media input/output control section 43 controls a pickup (notshown), and writes data acquired from the cache memory 42 to the opticaldisk medium 51 mounted at the predetermined location of the optical diskdrive 32, or reads the data recorded on the optical disk medium 51 andsupplies the read data to the cache memory 42.

The optical disk medium 51 is a storage medium supported by the opticaldisk drive 32. The optical disk medium 51 is formatted according to apredetermined file system, such as a universal disk format (UDF), forexample. The process of recording information onto the optical diskmedium 51 is performed in a method that complies with the format of thisfile system. This process is performed by software (an applicationprogram or a driver) that operates under control of the CPU 21.Therefore, the optical disk drive 32 only executes instructions suppliedfrom the CPU 21, and does not analyze or operate the format of the filesystem of the optical disk medium 51.

Note that, although the optical disk medium 51 is used as an exemplarystorage medium in the following description, any storage medium isapplicable that is capable of having recorded thereon the filecontaining the AV data as described below. Examples of such storagemedia include magnetic storage media such as a magnetic tape and a harddisk, magneto-optical disks such as an MD (Mini-Disk (registeredtrademark)), and semiconductor memories such as a flash memory.

Returning to FIG. 1, the input section 33 connected to the internal bus30 includes input devices such as a keyboard and a mouse, for example.The input section 33 accepts a user instruction via such an inputdevice, and supplies the user instruction to the CPU 21 or the like viathe internal bus 30. The output section 34 includes output devices suchas a display formed by a cathode ray tube (CRT) or a liquid crystaldisplay (LCD) and a loudspeaker, for example. The output section 34outputs the AV data or the like supplied via the internal bus 30 as animage, sound, or the like. The storage section 35 includes a storagemedium such as a hard disk. For example, the storage section 35 storesthe program, the data, etc., executed by the CPU 21, and supplies suchinformation via the internal bus 30 as necessary. A removable medium 37,such as a magnetic disk, an optical disk, a magneto-optical disk, or asemiconductor memory, is mounted as necessary at a predeterminedlocation on the drive 36. A computer program is read from the removablemedium 37 and installed into the storage section 35 as necessary.

The CPU 21 of the optical disk recording apparatus 11 having theabove-described structure transmits instructions to the networkinterface 31 via the internal bus 30 to allow the network interface 31to control the video camera 13 connected thereto via the network cable12 and acquire a video/audio signal (i.e., the AV data) from the videocamera 13 in a synchronized manner. The network interface 31 contains abuffer memory, and is capable of storing the acquired signal temporarilyto reduce a difference in speed between communication via the internalbus 30 and communication via the network cable 12. The network interface31 supplies the acquired AV data to the main memory 23 via the internalbus 30, so that the main memory 23 holds the AV data.

The CPU 21 performs a signal processing or a format conversion processon the AV data (file) held by the main memory 23 as necessary, andsupplies the file to the optical disk drive 32 via the internal bus 30so that the optical disk drive 32 writes the file to the optical diskmedium 51.

FIG. 2 is a schematic diagram illustrating an exemplary structure of thesoftware executed by the CPU 21 in FIG. 1.

In FIG. 2, the structure of the software is divided into a user mode(i.e., the uppermost layer) 100, a kernel mode (i.e., a middle layer)101, and a hardware abstraction layer (i.e., the lowermost layer) 102.First, a capture application 111 that operates in the user mode 100issues to a “network interface-controlling device driver” (i.e., anetwork I/F-controlling device driver) 121, which operates in the kernelmode 101 and is used to control the network interface 31, an instructionto read the video/audio signal from the video camera 13 in FIG. 1, andallows the network interface 31 to transfer the video/audio signal heldin the buffer memory in the network interface 31 to the main memory 23.Thereafter, the signal conversion process or the format conversionprocess necessary in the main memory 23 is performed. Here, the networkinterface-controlling device driver 121 uses an internal bus driver 124,which is used to control the bus interface 25, and an interface in thehardware abstraction layer 102 to access a register in the I/O bridge 22or the like, and issues the instruction to read and transfer thevideo/audio signal to the network interface 31 via the internal bus 30.

Further, the capture application 111 issues, to a file system driver 122that operates in the kernel mode 101, an instruction to write the filesof the video and audio data subjected to format conversion in the mainmemory 23. This writing instruction is transferred from the file systemdriver 122 to the optical disk drive 32 via an “optical diskdrive-controlling device driver” 123, which is used to control theoptical disk drive 32, the internal bus driver 124, and the internal bus30. Here, it is necessary to specify at which address on the opticaldisk medium 51 (i.e., at which address in the recording area of theoptical disk medium 51) a data stream (i.e., the data of the files) isto be written. In the present system, the capture application 111 isable to set (i.e., specify), for the file system driver 122, the addressat which the data stream is to be written.

FIG. 3 shows an exemplary file format used when the system of FIG. 1writes the video/audio signal to the optical disk medium 51. Asillustrated in FIG. 3, the video/audio signal to be recorded on theoptical disk medium 51 is converted into a file in which the video data,the audio data, and the related data are gathered separately. In anexample of FIG. 3, the video/audio signal is managed in the main memory23 as three files, i.e., a video file (Video) 201, an audio file(Audio1) 202, an audio file (Audio2) 203, which are constructed under amaster file 200, in which pointers to the subordinate files aredescribed.

The video file 201 is a file that complies with a material exchangeformat (MXF), and is composed of a header portion 211, a body portion212, and a footer portion 213. The header portion 211 is 64-kilobytedata, for example. The header portion 211 has a so-called KLV (Key,Length, Value) structure. That is, within the header portion 211, thedata is arranged in the following order: Key, Length, and Value. A16-byte label that complies with SMPTE 298M standard and indicates whichtype of data is arranged in Value is arranged in Key. A data length ofthe data arranged in Value is arranged in Length. Actual data isarranged in Value.

Specifically, in the example of FIG. 3, in the header portion 211 of thevideo file 201, KL data (KL) 221 is followed by a header (Header) 222 asValue of the KL data (KL) 221; and KL data (KL) 225 is followed byheader metadata (Header Metadata) 226 as Value of the KL data (KL) 225.Note that as the header portion 211 has a fixed length, a filler(Filler), i.e., data used for stuffing, is arranged so as to have theKLV structure. That is, a filler (Filler) 224 is arranged so as tofollow KL data (KL) 223, and a filler (Filler) 228 is arranged so as tofollow KL data (KL) 227.

In the body portion 212, the video data (i.e., a part of the AV data) isconstructed as a 64-kilobyte alignment of KLV structures, for example.Value of each KLV structure is composed of either an elementary streamof the video data as encoded according to an MPEG (Moving PictureExperts Group) system (i.e., MPEG ES (MPEG Elementary Stream)) or afiller. In the example of FIG. 3, KL data (KL) 231 is arranged at thetop of the body portion 212, followed by an elementary stream (MPEG ES)232 as Value of the KL data (KL) 231; and KL data (KL) 233 is arrangedso as to follow the elementary stream (MPEG ES) 232, and is followed bya filler (Filler) 234 as Value of the KL data (KL) 233. They arefollowed by similar KLV structures, which is followed by KL data (KL)235, followed by an elementary stream (MPEG ES) 236 as Value of the KLdata (KL) 235. Then, KL data (KL) 237 is arranged so as to follow theelementary stream (MPEG ES) 236, and is followed by a filler (Filler)238 as Value of the KL data (KL) 237.

Similar to the header portion 211, the footer portion 213 is constructedas 64-kilobyte data having the KLV structure, for example. Specifically,in the example of FIG. 3, KL data (KL) 241 is arranged at the top of thefooter portion 213, followed by a footer (Footer) 242 as Value of the KLdata (KL) 241; and KL data (KL) 243 is arranged so as to follow thefooter (Footer) 242, and is followed by a filler (Filler) 244.

The audio file 202 is also a file that complies with the MXF, and hasthe basically same structure as that of the video file 201. The audiofile 202 is composed of a header portion 251, a body portion 252, and afooter portion 253.

As illustrated in FIG. 3, the header portion 251 and the body portion252 as recorded are different in structure from those in MXF format. InFIG. 3, the header portion 251 and the body portion 252 as recorded aredenoted by reference numerals 251A and 252A, respectively, while thosein MXF format are denoted by reference numerals 251B and 252B,respectively. Specifically, in the example of FIG. 3, the header portion251B in MXF format is composed of KL data (KL) 261, a header (Header)262, KL data (KL) 263, a filler (Filler) 264, KL data (KL) 265, headermetadata (Header Metadata) 266, KL data (KL) 267, and a filler (Filler)268, which are arranged in this order. In the body portion 252B in MXFformat, the audio data (i.e., a part of the AV data) is constructed asan alignment of KLV structures. Value of each KLV structure is composedof either an elementary stream (AES3 (LPCM)) of the audio data asencoded according to an AES (Audio Engineering Society) 3 system (i.e.,an LPCM (Linear Pulse Code Modulation) system) or a filler (Filler).Specifically, KL data (KL) 271 is arranged at the top of the bodyportion 252B, and is followed by an elementary stream (AES3 (LPCM)) 272as Value of the KL data (KL) 271. They are followed by similar KLVstructures. Then, KL data (KL) 274 and a filler (Filler) 275 arearranged so as to follow an elementary stream (AES3 (LPCM)) 272.

In contrast, the header portion 251A as recorded is composed of all thecomponents of the header portion 251B and the KL data 271 contained inthe body portion 252B. Naturally, in the body portion 252A as recorded,the components from the elementary stream 272 to the filler (Filler) 275are arranged.

Similar to the footer portion 213 of the video file 201, the footerportion 253 is 64-kilobyte data having the KLV structure, for example.In the example of FIG. 3, the footer portion 253 is composed of KL data(KL) 281, a footer (Footer) 282, KL data (KL) 283, and a filler (Filler)284, which are arranged in this order.

The audio file 203 is a file containing audio data of a channeldifferent from that of the audio file 202, and has the same structure asthat of the audio file 202. Therefore, the audio file 203 complies withthe MXF, and is composed of a header portion 291, a body portion 292,and a footer portion 293.

A header portion 291B in MXF format is composed of KL data (KL) 301, aheader (Header) 302, KL data (KL) 303, a filler (Filler) 304, KL data(KL) 305, header metadata (Header Metadata) 306, KL data (KL) 307, and afiller (Filler) 308, which are arranged in this order. A body portion292B in MXF format is composed of KL data (KL) 311, an elementary stream(AES3 (LPCM)) 312, . . . , an elementary stream (AES3 (LPCM)) 313, KLdata (KL) 314, and a filler (Filler) 315, which are arranged in thisorder.

In contrast, a header portion 291A as recorded is composed of all thecomponents of the header portion 291B and the KL data 311 contained inthe body portion 292B. Naturally, in a body portion 292A as recorded,the components from the elementary stream 312 to the filler (Filler) 315are arranged.

Similar to the footer portion 253 of the audio file 202, the footerportion 293 is 64-kilobyte data having the KLV structure, for example.In the example of FIG. 3, the footer portion 293 is composed of KL data(KL) 321, a footer (Footer) 322, KL data (KL) 323, and a filler (Filler)324, which are arranged in this order.

In FIG. 3, the video/audio signal is composed of a single video file andtwo audio files. However, the number of video files and that of audiofiles may be any number. Further, the video/audio signal may alsoinclude other types of files, such as a file composed of metadata, afile containing low-resolution data, or the like.

The capture application 111 in FIG. 2 (i.e., the CPU 21 in FIG. 1)acquires the video/audio signal from the video camera 13 and, whileallowing the main memory 23 to hold the video/audio signal, converts thesignal into the file format as illustrated in FIG. 3, and then, allowsthe optical disk drive 32 to write each file to the optical disk medium51 sequentially.

At this time, the capture application 111 (i.e., CPU 21) allows theoptical disk drive 32 to write the header portion of each file afterwriting the footer portion thereof. The header portion of each fileneeds to have described therein a total recording length of the file andthe like. However, the total recording length and the like is aparameter that is not determined until the end of writing. Therefore, inthe case where writing to the storage medium is performed in an ordinaryorder (i.e., the header, then the body, and then the footer), it isnecessary to write the header portion again to modify the totalrecording length and the like, at least after writing a final part ofthe body portion. This involves a seek from one location to anotherdistant location within the recording area of the optical disk medium51, which may result in considerable reduction in writing performance.

As such, although the header is logically located at a forward positionin the file format, the above-described method as disclosed in JapanesePatent Laid-open No. 2005-4853 secures, in arrangement, an area for theheader at a location to the rear of an area for the footer, and, afterrecording the footer portion, records information of the header portionin an area contiguous to that of the footer portion, thereby preventingoccurrence of the seek and reduction in writing performance.

When this method is adopted and the capture application 111 isabnormally terminated in the course of writing the file, for example,the file may not be recognized in the file system of the optical diskmedium 51 (i.e., the file may be regarded as not having been recorded atall), as the writing of the header portion is not completed.

In the case where an unexpected trouble occurs in the kernel mode 101 orin any lower layer in the software structure of FIG. 2, or in the casewhere the video/audio signal inputted from the video camera 13 involvesabnormality, for example, some special solution will be required. In thecase where only the capture application 111 in the user mode 100 of FIG.2 is abnormally terminated, however, the file system driver 122 is ableto allow the file system to reflect information concerning the writingof the file up to the abnormal termination, thereby making the filerecognizable in the file system.

As such, the capture application 111 provisionally secures, beforewriting the body portion, a header area in which the header portion isto be recorded. Thus, in the case where only the capture application 111in the user mode 100 is abnormally terminated (incidentally, the captureapplication 111 is most likely to be terminated abnormally), a “writingprocess” can be terminated normally (i.e., the file can be closed) tomake the data written up to the abnormal termination a recognizablefile.

FIG. 4 is a schematic diagram illustrating an operation model of thewriting process. In this writing process, first, the header area towhich the header portion of each file is written is securedprovisionally (process 401).

Next, body fragment areas to which the elementary streams of the bodyportions of the audio data (Audio1) 202, the audio data (Audio2) 203,and the video data (Video) 201 are written consecutively are securedsequentially, and the data is recorded therein sequentially. Then, atthe time when the last body fragment area has been secured and data hasbeen recorded therein, footer areas to which the footer portions arewritten are secured, and the footer portions of the audio data (Audio1)202, the audio data (Audio2) 203, and the video data (Video) 201 arerecorded therein. Thereafter, a header area to which the header portionsare written is secured again based on the body areas and the footerareas, and the header portions of the audio data (Audio1) 202, the audiodata (Audio2) 203, and the video data (Video) 201 are recorded therein(process 402).

As described above, while the header area is secured in process 401, thelocation thereof in the recording area of the optical disk medium 51 isupdated in process 402. Specifically, referring to FIG. 4, a provisionalheader area (“Audio1” header (provisional)) 411 for the audio file 202secured in process 401 is changed to a header area (“Audio1” header) 414in process 402; a provisional header area (“Audio2” header(provisional)) 412 for the audio file 203 secured in process 401 ischanged to a header area (“Audio2”, header) 415 in process 402; and aprovisional header area (“Video” header (provisional)) 413 for the videofile 201 secured in process 401 is changed to a header area (“Video”header) 416 in process 402.

In the case where some trouble occurs during the writing process by thecapture application 111 to terminate the process (i.e., in the casewhere only the capture application 111 in the user mode 100 has beenabnormally terminated), the provisional securing of the header areabefore the recording of the body portions as described above enables thefile system driver 122 that operates in the kernel mode 101 to allowinformation concerning areas that have been secured and locations wherethe data has been recorded until the abnormal termination to bereflected in the file system of the optical disk medium 51. Accordingly,the file of which the writing has not been completed can be recognizedas a file on the file system.

Specific flows of processes will now be described below.

First, an exemplary flow of a capturing process will now be describedbelow with reference to a flowchart of FIG. 5. In the capturing process,the CPU 21 that executes the capture application 111 (hereinafterreferred to as the “capture application 111”) acquires the video/audiosignal (i.e., the AV data) from the video camera 13 and allows the mainmemory 23 to hold the video/audio signal.

In performing the capturing process, the capture application 111 usesthe network interface-controlling device driver 121 to transfer thevideo/audio signal (i.e., the AV data) from the video camera 13 to themain memory 23 and performs the signal processing and the formatconversion process on the video/audio signal.

For example, when a user uses the input section 33 to issue aninstruction to capture (acquire) the video/audio signal, the captureapplication 111 starts the capturing process, and issues to the networkinterface-controlling device driver 121 an instruction to start captureat step S1. In accordance with this instruction, the networkinterface-controlling device driver 121 allows the network interface 31to start the capture of the video/audio signal from the video camera 13.In accordance with this control, the network interface 31 acquires thevideo/audio signal from the video camera 13, and holds the video/audiosignal in the internal buffer (not shown) temporarily.

At step S2, the capture application 111 secures, in a storage area ofthe main memory 23, an area of a predetermined data size for holding thevideo/audio signal. This predetermined data size corresponds to, forexample, a fixed amount of data as measured in time (e.g., two secondsof data, 60 data frames, etc.).

At step S3, the capture application 111 checks the data amount of thevideo/audio signal accumulated in the internal buffer of the networkinterface 31, and determines whether the data amount of the video/audiosignal accumulated therein corresponds to the size of the area securedin the main memory 23 at step S2. The capture application 111 waitsuntil the determination at step S3 becomes affirmative.

When it is determined that the data amount of the video/audio signalaccumulated in the internal buffer of the network interface 31corresponds to the size of the area secured in the main memory 23, thecapture application 111 proceeds to step S4. At step S4, the captureapplication 111 uses the network interface-controlling device driver 121to issue to the network interface 31 an instruction to transfer the dataof the video/audio signal to the main memory 23. In accordance with thisinstruction, the network interface 31 transfers the data of thevideo/audio signal accumulated in the internal buffer to the main memory23 via the internal bus 30.

At step S5, the capture application 111 performs the signal processingand the format conversion process on the video/audio signal transferredto the main memory 23 to generate data that will be written to theoptical disk medium 51 as the body fragments of the video file 201, theaudio file 202, and the audio file 203 as illustrated in FIG. 3.

At step S6, the capture application 111 determines whether a request tostop the capturing process has been made, and if it is determined thatsuch a request has not been made, the capture application 111 returns tostep S2 and repeats the subsequent processes. Specifically, theabove-described processes are performed on data newly acquired by thenetwork interface 31 from the video camera 13 and accumulated in theinternal buffer of the network interface 31. When, after theabove-described processes of steps S2 to S6 are repeated, it isdetermined at step S6 that the request to stop the capturing process hasbeen made by the user operating the input section 33, for example, thecapture application 111 proceeds to step S7. At step S7, the captureapplication 111 uses the network interface-controlling device driver 121to issue to the network interface 31 an instruction to stop the capture.When this capture stop instruction is issued, the network interface 31stops the acquisition of the video/audio signal from the video camera13. After issuance of the capture stop instruction, the captureapplication 111 finishes the capturing process.

As a result of the above-described capturing process, the file of thevideo/audio signal having the structure as described above withreference to FIG. 3 is generated in the main memory 23.

Independently of the above-described capturing process, the captureapplication 111 performs a recording process. In the recording process,the capture application 111 records each file of the video/audio signalaccumulated in the main memory 23 by the capturing process onto theoptical disk medium 51 mounted on the optical disk drive 32. Therecording process can be performed in parallel with the capturingprocess.

An exemplary flow of the recording process will now be described belowwith reference to a flowchart of FIG. 6.

When the recording process is started based on a user instructionaccepted via the input section 33, for example, the capture application111 allows the file system driver 122 to secure the provisional headerarea at step S21. The location where the provisional header area issecured is arbitrary. The details thereof will be described later. Thissecuring of the provisional header area is not reflected at this time inthe file system in the optical disk medium 51 (i.e., address informationof the header area is not recorded at this time in managementinformation recorded on the optical disk medium 51). Instead, the filesystem driver 122 executed by the CPU 21 virtually holds areainformation concerning the header area in the main memory 23.

Specifically, before the recording of the body portions, the captureapplication 111 allows the file system driver 122 to virtually set theheader area at an arbitrary area (location) within the recording area ofthe optical disk medium 51 and hold the area information concerning theprovisional header area in the main memory 23 to secure the header areaprovisionally (i.e., secure the provisional header area).

After securing the provisional header area, the capture application 111,at step S22, performs a seek corresponding to the header size inconnection with addresses accessed in the main memory 23. That is, thecapture application 111 performs a seek corresponding to the headerportions so that the file system driver 122 can acquire from the mainmemory 23 the body portion of the file to be processed. Actual writingof the header portion to the optical disk medium 51 is not carried out,and it has not been determined yet to which area of the optical diskmedium 51 the body portion, which is the next to be written to theoptical disk medium 51, will be written. Therefore, no actual seekoccurs in the optical disk drive 32. Note that actual writing of theheader portion to the provisional header area may naturally be carriedout.

At step S23, the capture application 111 accesses the main memory 23 todetermine whether body fragment data to be recorded next has beengenerated in the main memory 23 by the above-described capturingprocess. If it is determined that the body fragment data to be recordedhas been generated and that further recording onto the optical diskmedium 51 is required, the capture application 111 proceeds to step S24.At step S24, the capture application 111 controls the file system driver122 to secure, in continuous free space on the optical disk medium 51,the body fragment areas of a size corresponding to the body fragment ofeach of the audio file 202, the audio file 203, and the video file 201successively in this order.

After securing the body fragment areas, the capture application 111controls the file system driver 122 to record the body fragment data inthe secured body fragment areas at step S25. After the process of stepS25 is completed, the capture application 111 returns to step S22, andrepeats the subsequent processes until it is determined that there is nobody fragment data that has been generated in the main memory 23 by thecapturing process and remains to be written to the optical disk medium51.

Then, when it is determined at step S23 that the recording of furtherbody fragments is not required because no yet-to-be-recorded bodyfragments exist in the main memory 23, for example, the captureapplication 111 proceeds to step S26.

At step S26, the capture application 111 determines whether thecapturing process has been stopped, and if it is determined that thecapturing process has not been stopped, the capture application 111,estimating that the main memory 23 is only temporarily lacking in thegenerated body fragments and that the recording of further bodyfragments will be required again, returns to step S22 to record thefurther body fragments.

If it is determined at step S26 that the capturing process has beenstopped, the capture application 111 terminates the writing of the bodyfragments normally, and proceeds to step S27. At step S27, the captureapplication 111 controls the file system driver 122 to secure, incontinuous free space following the last body fragment area on theoptical disk medium 51, the footer areas for the footer portion of eachof the audio file 202, the audio file 203, and the video file 201successively in this order. Then, at step S28, the capture application111 controls the file system driver 122 to record the data of the footerportions in the footer areas.

When the recording process has reached this stage, the total recordinglength, which should be recorded in the header portion, can bedetermined. Accordingly, at step S29, the capture application 111controls the file system driver 122 to re-secure, in continuous freespace following the footer areas on the optical disk medium 51, theheader area in which the header portions of the audio file 202, theaudio file 203, and the video file 201 are to be recorded successivelyin this order. In other words, the capture application 111 controls thefile system driver 122 to update the area information concerning theprovisional header area that has been provisionally secured at step S21and held in the main memory 23 to the continuous free space that followsthe footer areas (i.e., modify the header area).

After re-securing of the header area, the capture application 111controls the file system driver 122 to record the header portions in there-secured header area at step S30. After issuance of an instruction torecord the header portions, the capture application 111 terminates therecording process normally.

As described above, the capture application 111 controls the file systemdriver 122 to secure the provisional header area in the initial step ofthe recording process, then secure the body fragment areas in theoptical disk medium 51 and write the body fragments thereto, then securethe footer areas and write the footer portions thereto, and thenre-secure the header area in the space following the footer areas (i.e.,modify the header area) and write the header portions to the new headerarea.

In the case where the recording process is terminated abnormally in thecourse of the process, processes that otherwise should be performedthereafter are not performed. When the recording process is terminatednormally or abnormally (i.e., when a file close instruction is receivedfrom the OS), the file system driver 122 performs a termination processto cause the file system in the optical disk medium 51 to reflect fileinformation concerning each of the above-described files and areainformation concerning each of the areas to which the files have beenwritten.

An exemplary flow of the termination process will now be described belowwith reference to a flowchart of FIG. 7.

When the termination process is started, the file system driver 122allows the file system (i.e., the management information) in the opticaldisk medium 51 to reflect the secured header area at step S51, andallows the file system to reflect, with respect to the other areas, thelocations where the data have been recorded at step S52. When theprocess of step S52 is completed, the file system driver 122 finishesthe termination process.

In the case where the recording process is terminated normally, the filesystem driver 122 performs the above-described termination process, sothat the location of the header area where the header portions haveactually been written is written to the file system. In the case wherethe recording process is terminated abnormally, the file system driver122 performs the termination process in a similar manner. In the case ofthe abnormal termination, the provisional header area has been securedat the time of the abnormal termination; therefore, the file systemdriver 122 allows the file system in the optical disk medium 51 toreflect the secured provisional header area.

That is, because the capture application 111 that operates in the usermode 100 secures the provisional header area before the writing of thebody portions in the recording process, it is possible to allow the filesystem to reflect the provisional header area, even if the abnormaltermination occurs. Therefore, it is possible to allow the data that hasbeen written to the optical disk medium 51 until the abnormaltermination to be recognizable as a file without the need for performinga data recovery process as described in Japanese Patent Laid-open No.2006-65912 mentioned above.

That is, only by restarting the capture application 111, which wasabnormally terminated, the optical disk recording apparatus 11 canhandle the data that has been written to the optical disk medium 51until the abnormal termination as a file, without the need to perform aspecial data recovery process that does not comply with the file systemof the optical disk medium 51. Therefore, subsequently, the optical diskrecording apparatus 11 is able to easily carry out a process, such asresuming the interrupted writing process, deleting the file, or thelike, by using the restarted capture application 111.

In addition, even in the case where the recording process has beenterminated abnormally, the file system is stored properly and the datathat has been written to the optical disk medium 51 until the abnormaltermination is recognized as a file by the file system. Therefore, theoptical disk recording apparatus 11 and any other apparatuses thatsupport the file system of the optical disk medium 51 are able to handlethe data that has been written to the optical disk medium 51 until theabnormal termination as a file. For example, suppose that the opticaldisk medium 51 is removed from the optical disk drive 32 and mounted onanother optical disk drive (or another apparatus) after the abnormaltermination of the recording process. In this case, the data that hasbeen written to the optical disk medium 51 until the abnormaltermination can be processed as a file by the other optical disk drive(or the other apparatus), even if the other optical disk drive (or theother apparatus) does not have a data recovery capability.

Further, the securing of the provisional header area is easilyachievable by the capture application 111, by simply generating theinformation concerning the virtual header area and holding theinformation in the main memory 23. Even in the case where the headerportions are actually written to this provisional header area, aprocessing load therefor is light because the amount of data in theheader area is, in general, sufficiently small as compared to that ofthe body area.

In the case where the recording process is terminated normally, thecapture application 111 re-secures the header area to which the headerportions are written (i.e., updates the header area as secured). Thisprocess is achieved easily by simply updating the information in themain memory 23, with a light processing load.

Further, the above-described manner of processing by the captureapplication 111 allows the file system driver 122 to perform a similartermination process regardless of whether the recording process isterminated normally or abnormally.

As described above, without the need for any special structure or datarecovery process, the optical disk recording apparatus 11 can accomplishthe data recording easily in such a manner as to comply with the filesystem of the optical disk medium 51 regardless of whether the recordingprocess is terminated normally or abnormally, while observing arecording area securing rule that the data should be recorded in thefollowing order: the body, the footer, and the header. In addition, thedata recorded in this manner can be recognized as a file in the filesystem, even if the writing of the data is terminated in the course ofwriting. Therefore, it is easy for the optical disk recording apparatus11 to resume the writing of the data or delete the data.

As noted earlier, the location where the provisional header area issecured at step S21 of the recording process is arbitrary. Specificexamples thereof will now be described below with reference to FIGS. 8Ato 8D. In FIGS. 8A to 8D, a recording area 501 is a band-shapedrepresentation of the recording area of the optical disk medium 51, inwhich inner tracks are to the left of outer tracks. On an inner side ofthe recording area 501, a file system (FS) management area 511 isprovided. In the file system management area 511, the file system of theoptical disk medium 51 is recorded. In general, the writing processproceeds from the inner side toward an outer side, and free space towhich data, such as the video/audio signal, can be written is providedon the outer side of the file system management area 511.

FIG. 8A illustrates an exemplary case where the provisional header areais secured at the top of the free space to which the data is to bewritten. In FIG. 8A, a provisional header area (HEADER (PROVISIONAL))512 is secured at the innermost location (i.e., the top) in the freespace. At locations contiguous to the provisional header area 512, abody area (BODY) 513 to which the body portions are to be written, afooter area (FOOTER) 514 to which the footer portions are to be written,and a header area (HEADER) 515 to which the header portions are to bewritten are secured in this order. Therefore, in this case, even if theheader portions are written to the provisional header area 512 firstafter the start of the recording, a significant seek does not occur inthe optical disk drive 32. Unfortunately, however, in this method asillustrated in FIG. 8A, regardless of whether the header portions areactually written to the provisional header area 512, the provisionalheader area 512 may remain significantly unavailable for use even afterthe header area 515 is secured.

Alternatively, as illustrated in FIG. 8B, the provisional header area512 may be secured at the outermost location in the free space (i.e., atthe end of the free space), for example. When this method is adopted,the body area 513, the footer area 514, and the header area 515 can besecured so as to be arranged continuously, starting at the top of thefree space and extending outward. This, for example, eliminates the needto re-secure the header area when the free space is exhausted by thebody area 513 and the footer area 514, as the provisional header area512 can be used as the header area 515. A disadvantage of this method isthat, if the header portions are actually written to the provisionalheader area 512 when securing the provisional header area 512, asignificant seek occurs in the optical disk drive 32.

Alternatively, as illustrated in FIG. 8C, the provisional header areamay be secured in a partition different from that of the rest of the AVdata, for example. For example, in the case where a real-time type offile that requires reading of data from the optical disk medium 51 andreproduction of the data read therefrom to be performed in parallel(e.g., a file of video, audio, or other types of data that involves theneed to maintain a reading rate at a predetermined rate or higher) and anon-real-time type of file that does not require the reading of data andthe reproduction thereof to be performed in parallel (e.g., a file oftext or other types of data that does not involve the need to maintainthe reading rate at a predetermined rate or higher) are recorded inmutually different partitions (e.g., inner and outer partitions) in therecording area 501, it may be so arranged that the body area 513, thefooter area 514, and the header area 515 are all secured in partition A(which is used for recording the real-time type of file) while only theprovisional header area 512 is secured in partition B (which is used forrecording the non-real-time type of file). This prevents the securing ofthe provisional header area 512 from reducing the space available forrecording the body area 513, the footer area 514, and the header area515. Because data of the provisional header portion is not contained inthe partition used for recording the real-time type of file, it is easyto find the file when the writing thereof is abnormally terminated inthe course of writing. That is, it is easy to determine whether theabnormal termination has occurred in the course of recording.

Alternatively, as illustrated in FIG. 8D, an unrecorded and unsecuredarea used in a sparse file or the like may be used to secure theprovisional header area 512, for example. In the UDF, for example, anarea securement descriptor (i.e., an allocation descriptor) 521 can beset as the unrecorded and unsecured area. Use of the area securementdescriptor enables the capture application 111 to secure the provisionalheader area 512 without actually occupying any part of the recordingarea of the optical disk medium 51. Note that, when data is written tothe provisional header area 512, the data may be stored in a virtualarea provided in the main memory 23, for example, without actuallyrecording the data onto the optical disk medium 51 (i.e., data writingmay be performed virtually). Alternatively, as in the case of theexample as illustrated in FIG. 8C, it may be so arranged that theprovisional header area 512 is re-secured (temporarily saved) in thepartition to which the non-real-time type of file is written, then thisfact is reflected in the file system (i.e., the file system managementarea 511) of the optical disk medium 51, and then, after the recordingof the body portion and the footer portion is completed, the header area515 is re-secured to the rear of the footer area 514 (so as to becontiguous to and outside of the footer area 514), and then this fact isreflected in the file system (i.e., the file system management area 511)of the optical disk medium 51.

An exemplary recording model in the case where the file format of theoptical disk medium 51 is the UDF will now be described below.

FIG. 9 illustrates a recording model in the case where theabove-described recording process is terminated normally in a UDF filesystem. In FIG. 9, a part of the recording area of the optical diskmedium 51 to which consecutive addresses (i.e., logical sector numbers(LSNs)) are allocated is represented by two vertical bands. A recordingarea 601A on the left-hand side of FIG. 9 is an area in whichinformation used for managing the file system (i.e., the file systemmanagement area) is mainly recorded. A recording area 601B on theright-hand side of FIG. 9 is an area in which substance (extent) of thefile is recorded.

In FIG. 9, allowing the secured header area to be reflected in the filesystem refers to writing the file management information to therecording area 601A, for example. To management information (ParentDirectory) 611 of a parent directory of each of the audio file (Audio1),the audio file (Audio2), and the video file (Video), file identifiers(i.e., file identifier descriptors) for identifying each of the filesare written (in the case of an example of FIG. 9, the file identifiersare written to space within a file entry of the management information(Parent Directory) 611 of the parent directory).

In each of the file identifiers, a file name, an address of a fileentry, and the like are recorded. In addition, in an area specified byeach of the file identifiers, a corresponding one of a file entry 612 ofthe audio file (Audio1), a file entry 613 of the audio file (Audio2),and a file entry 614 of the video file (Video) is recorded. In each ofthe file entries 612 to 614, a recording length of the data of thecorresponding file, recording area information (i.e., allocationdescriptors) of the corresponding file, etc., are recorded.

In the recording area 601B, body fragments #1 to #n, which are thesubstance of the files, are recorded as a ring data sequence (i.e., ringdata #1 to #n). Each ring data is composed of one body fragment of theaudio file (Audio1), one body fragment of the audio file (Audio2), andone body fragment of the video file (Video) put together. Then, in thefooter area that follows the body area, the footer portions (i.e.,footers 633 to 635) are recorded, while in the header area that followsthe footer area, the header portions (i.e., headers 636 to 638) arerecorded (i.e., the address of the header area as secured is changed(arrow 651)). When the recording process has been terminated normally,the file system driver 122 performs the termination process to carry outwriting to update the above-described file system management information(i.e., the file entries 611 to 614) in the recording area 601A.

At this time, for example, the file system driver 122 updates therecording length, the recording area information, etc., contained in thefile entry 612 so that not the provisional header area 621, which hasinitially been secured, but the header area 636 as secured subsequentlyis regarded as the header area. As a result, correspondence between thefile entry 612 and the header area is indicated not by arrow 641 but byarrow 642.

Similarly, the file system driver 122 updates the recording length, therecording area information, etc., contained in the file entry 613 sothat not the provisional header area 622 but the header area 637 isregarded as the header area. Also, the file system driver 122 updatesthe recording length, the recording area information, etc., contained inthe file entry 614 so that not the provisional header area 623 but theheader area 638 is regarded as the header area.

FIG. 10 illustrates a recording model in the case where theabove-described recording process is terminated abnormally in the UDFfile system. In FIG. 10, as in the case of FIG. 9, the recording lengthof the data of the corresponding file, the recording area information(i.e., the allocation descriptors) of the corresponding file, etc., arerecorded in each of the file entries 612 to 614.

Suppose, for example, that the recording process is terminatedabnormally in the course of writing the body portions. In this case, thefile system driver 122 performs the termination process, as when therecording process is terminated normally, to carry out writing to updatethe above-described file system management information (i.e., the fileentries 611 to 614) in the recording area 601A.

At this time, for example, the file system driver 122 updates therecording length, the recording area information, etc., contained in thefile entry 612 so that the provisional header area 621, which has beensecured at the time of the abnormal termination, is regarded as theheader area. As a result, the correspondence between the file entry 612and the header area is indicated by arrow 641.

Similarly, the file system driver 122 updates the recording length, therecording area information, etc., contained in the file entry 613 sothat the provisional header area 622 is regarded as the header area.Also, the file system driver 122 updates the recording length, therecording area information, etc., contained in the file entry 614 sothat the provisional header area 623 is regarded as the header area.

In this case, because no recording has been performed on the headerarea, the file system driver 122 returns zero (0) to a request forreading the header portion of each file. This allows the halfwayrecording to be reflected in the file system.

Thereafter, the capture application 111 as restarted can detect thehalfway recording by once examining the recorded data of the files, andthereby resume the recording or re-secure the header of each file atthis point to terminate the “recording process” normally.

FIG. 11 illustrates an exemplary recording model in the UDF file systemin which the technique of re-securing the header area immediately afterthe recording is applied. Here, immediately after the start of therecording, the header portions (i.e., the provisional header portions621 to 623) are secured at the top of the continuous recording area, andthe proper data is once recorded therein. Thereafter, as in the case ofFIG. 9, the body area and the footer area are secured in continuousspace, and the proper data is recorded in each of the areas. Uponcompletion of this recording, the header portion of each file isrecorded in a header area (i.e., the header areas 636 to 638) re-securedat a location immediately preceding the corresponding file entry (i.e.,the file entries 612 to 614) in the recording area 601A as illustratedin FIG. 11. Upon completion of this recording, the file system driver122 records each file entry (note that writing of the header portionsand update of the file entries may be performed successively on afile-by-file basis). A seek distance at the time of recording accordingto this recording model is not significantly different from that of therecording model of FIG. 9. However, in the case where, when the file isopened for reproduction thereof, the file entries are accessed first andthen the reading of the header portions is performed, for example, theseek distance is reduced as compared to the recording model of FIG. 9,which may result in improved performance.

The above-described series of processes can be implemented by eitherhardware or software. In the case where the above-described series ofprocesses are implemented by software, a program that forms the softwareis installed from a network or a storage medium.

This storage medium may be the removable medium 37 as illustrated inFIG. 1, which is distributed, separately from the optical disk recordingapparatus 11, for providing the program to the user and which has theprogram recorded thereon, such as a magnetic disk (e.g., a flexibledisk), an optical disk (e.g., a CD-ROM (Compact Disc-Read Only Memory)or a DVD (Digital Versatile Disk)), a magneto-optical disk (e.g., an MD(Mini-Disk)(a registered trademark)), or a semiconductor memory.Alternatively, the above storage medium may be the ROM 24 or the harddisk contained in the storage section 35, which is originally containedin the optical disk recording apparatus 11 and thus provided to the userand which has the program stored therein.

Note that the steps implemented by the program stored in the storagemedium may naturally be performed chronologically in the order asdescribed in the present specification but do not have to be performedchronologically. Some steps may be performed in parallel orindependently.

Also note that the components incorporated in a single apparatus in theforegoing description may be divided and incorporated separately intotwo or more apparatuses. Conversely, components that have been describedabove to be contained in different apparatuses may be incorporated intoa single apparatus. Also note that any other component that has not beenmentioned herein may naturally be added to any apparatus describedabove. Further, as long as the structure and operation of the system asa whole are not changed significantly, some of the components of oneapparatus may instead be contained in another apparatus. That is, itshould be understood by those skilled in the art that variousmodifications, combinations, sub-combinations and alterations may occurdepending on design requirements and other factors insofar as they arewithin the scope of the appended claims or the equivalents thereof.

The invention claimed is:
 1. A recording apparatus for recording a file stream composed of a header, a body, and a footer onto a storage medium, the apparatus comprising: a processor; and a memory coupled to the processor, the memory storing instructions executable by the processor, the instructions comprising: by holding in a main memory provisional header information for first audio data, second audio data, and video data and not recording any headers in the first header area; recording the body and the footer in the recording area of the storage medium; securing a second header area in the recording area after the body and the footer have been recorded in the recording area by changing the provisional header information for the first audio data, second audio data, and video data into non-provisional header information for the first audio data, second audio data, and video data, the second header area following areas in which the body and the footer have been recorded; recording the header for the file stream in the secured second header area; and recording information about the second header area in the storage medium, wherein a recording process for the file stream, when terminated normally and when terminated abnormally, is reflected in a file system of the storage medium, wherein when the recording process for the file stream is terminated abnormally an allocation descriptor for the provisional header is recorded onto the storage medium.
 2. The recording apparatus according to claim 1, wherein said first header area securing comprises setting the header area virtually to secure the header area provisionally.
 3. The recording apparatus according to claim 1, wherein said first header area securing comprises setting the header area at a top of free space of the recording area.
 4. The recording apparatus according to claim 1, wherein said first header area securing comprises setting the header area at an end of free space of the recording area.
 5. The recording apparatus according to claim 1, wherein said first header area securing comprises setting the header area in one of a plurality of partitions provided in the recording area that is different from a partition in which the body and the footer are recorded.
 6. The recording apparatus according to claim 1, wherein, the file system is UDF (Universal Disk Format), and said first or second header area securing arranges the header area in an unrecorded and unsecured area in the UDF.
 7. A method for recording a file stream composed of a header, a body, and a footer onto a storage medium, the method comprising: by holding in a main memory provisional header information for first audio data, second audio data, and video data and not recording any headers in the first header area; recording the body and the footer in the recording area of the storage medium; securing a second header area in the recording area after the body and the footer have been recorded in the recording area by changing the provisional header information for the first audio data, second audio data, and video data into non-provisional header information for the first audio data, second audio data, and video data, the second header area following areas in which the body and the footer have been recorded; recording the header for the file stream in the secured second header area; and recording information about the second header area in the storage medium, wherein a recording process for the file stream, when terminated normally and when terminated abnormally, is reflected in a file system of the storage medium, wherein when the recording process for the file stream is terminated abnormally an allocation descriptor for the provisional header is recorded onto the storage medium.
 8. A non-transitory computer-readable medium including a program executable by a processor for recording a file stream composed of a header, a body, and a footer onto a storage medium, where the program causes the processor to: by holding in a main memory provisional header information for first audio data, second audio data, and video data and not recording any headers in the first header area; record the body and the footer in the recording area of the storage medium; secure a second header area in the recording area after the body and the footer have been recorded in the recording area by changing the provisional header information for the first audio data, second audio data, and video data into non-provisional header information for the first audio data, second audio data, and video data, the second header area following areas in which the body and the footer have been recorded; recording the header for the file stream in the secured second header area; and recording information about the second header area in the storage medium, wherein a recording process for the file stream, when terminated normally and when terminated abnormally, is reflected in a file system of the storage medium, wherein when the recording process for the file stream is terminated abnormally an allocation descriptor for the provisional header is recorded onto the storage medium. 